yannick

Une autorité de certification (AC) est une entité chargée d’émettre des certificats numériques pour vérifier les identités sur l’internet. Bien que les AC publiques soient un choix populaire pour vérifier l’identité des sites web et autres services qui sont fournis au grand public, les AC privées sont généralement utilisées pour les groupes fermés et les services privés.

La création d’une autorité de certification privée vous permettra de configurer, de tester et d’exécuter des programmes qui nécessitent des connexions cryptées entre un client et un serveur. Avec une AC privée, vous pouvez émettre des certificats pour les utilisateurs, les serveurs ou les programmes et services individuels au sein de votre infrastructure.

Quelques exemples de programmes sur Linux qui utilisent leur propre AC privée sont OpenVPN et Puppet. Vous pouvez également configurer votre serveur web pour utiliser des certificats émis par une AC privée afin de faire correspondre les environnements de développement et de simulation aux serveurs de production qui utilisent TLS pour crypter les connexions.

Dans ce guide, nous allons apprendre comment mettre en place une autorité de certification privée sur un serveur Debian 10 et comment générer et signer un certificat de test en utilisant votre nouvelle AC. Vous apprendrez également comment importer le certificat public du serveur de l’AC dans le magasin de certificats de votre système d’exploitation afin de pouvoir vérifier la chaîne de confiance entre l’AC et les serveurs ou utilisateurs distants. Enfin, vous apprendrez comment révoquer des certificats et distribuer une liste de révocation de certificats pour vous assurer que seuls les utilisateurs et les systèmes autorisés peuvent utiliser les services qui reposent sur votre AC.

Conditions préalables

Pour suivre ce tutoriel, vous devrez avoir accès à un serveur Debian 10 pour héberger votre service OpenVPN. Vous devrez configurer un utilisateur non root avec privilèges sudo avant de commencer ce guide. Vous pouvez suivre notre guide de configuration initiale de serveur Debian 10 pour configurer un utilisateur avec les permissions appropriées. Le tutoriel joint permettra également de mettre en place un pare-feu, supposé rester en place tout au long de ce guide.

Ce serveur sera appelé Serveur AC dans ce tutoriel.

Assurez-vous que le serveur AC est un système autonome. Il ne sera utilisé que pour importer, signer et révoquer les demandes de certificats. Il ne doit pas gérer d’autres services et, dans l’idéal, il sera hors ligne ou complètement fermé lorsque vous ne travaillerez pas activement avec votre AC.

Remarque : la dernière section de ce tutoriel est facultative si vous souhaitez en savoir plus sur la signature et la révocation des certificats. Si vous choisissez de suivre ces étapes de pratique, vous aurez besoin d’un second serveur Debian 10 ou vous pouvez également utiliser votre propre ordinateur Linux local fonctionnant sous Debian ou Ubuntu, ou des distributions dérivées de l’un ou l’autre.

Étape 1 — Installation d’Easy-RSA

La première tâche de ce tutoriel consiste à installer l’ensemble de scripts easy-rsa sur votre serveur d’AC. easy-rsa est un outil de gestion d’autorité de certification que vous utiliserez pour générer une clé privée et un certificat racine public, que vous utiliserez ensuite pour signer les demandes des clients et des serveurs qui s’appuieront sur votre AC.

Connectez-vous à votre serveur AC en tant qu’utilisateur sudo non root que vous avez créé lors des étapes de configuration initiales et exécutez ce qui suit :

sudo apt update

sudo apt install easy-rsa

Vous serez invité à télécharger le package et à l’installer. Appuyez sur y pour confirmer que vous souhaitez installer le package.

À ce stade, vous disposez de tout ce dont vous avez besoin, installé et prêt pour utiliser Easy-RSA. Dans l’étape suivante, vous allez créer une infrastructure à clés publiques, puis vous commencerez à construire votre autorité de certification.

Étape 2 — Préparation d’un répertoire d’infrastructures à clés publiques

Maintenant que vous avez installé easy-rsa, il est temps de créer un squelette de l’infrastructure de clés publiques (ICP) sur le serveur AC. Assurez-vous que vous êtes encore connecté en tant qu’utilisateur non root et créez un répertoire easy-rsa Assurez-vous que vous n’utilisez pas sudo pour exécuter l’une des commandes suivantes, puisque votre utilisateur normal doit gérer et interagir avec l’AC sans privilèges élevés.

mkdir ~/easy-rsa

Cela créera un nouveau répertoire appelé easy-rsa dans votre dossier de base. Nous utiliserons ce répertoire pour créer des liens symboliques pointant vers les fichiers de packages easy-rsa que nous avons installés à l’étape précédente. Ces fichiers sont situés dans le dossier /usr/share/easy-rsa sur le serveur AC.

Créez les liens symboliques (symlinks) avec la commande ln :

ln -s /usr/share/easy-rsa/* ~/easy-rsa/

Remarque : alors que d’autres guides peuvent vous demander de copier les fichiers du package easy-rsa dans votre répertoire ICP, ce tutoriel adopte une approche par lien symbolique. Par conséquent, toute mise à jour du paquet easy-rsa sera automatiquement répercutée dans les scripts de votre ICP.

Pour restreindre l’accès à votre nouveau répertoire ICP, assurez-vous que seul le propriétaire peut y accéder en utilisant la commande chmod :

chmod 700 /home/sammy/easy-rsa

Enfin, initialisez l’ICP dans le répertoire easy-rsa :

cd ~/easy-rsa

./easyrsa init-pki

Output

init-pki complete; you may now create a CA or requests.

Your newly created PKI dir is: /home/sammy/easy-rsa/pki

Après avoir terminé cette section, vous disposez d’un répertoire qui contient tous les fichiers nécessaires pour créer une autorité de certification. Dans la section suivante, vous allez créer la clé privée et le certificat public pour votre AC.

Étape 3 — Création d’une autorité de certification

Avant de pouvoir créer la clé et le certificat privés de votre AC, vous devez créer et alimenter un fichier appelé vars avec quelques valeurs par défaut. Tout d’abord, vous allez cd dans le répertoire easy-rsa, puis vous allez créer et modifier le fichier vars avec nano ou votre éditeur de texte préféré :

cd ~/easy-rsa

nano vars

Une fois le fichier ouvert, collez les lignes suivantes et modifiez chaque valeur mise en évidence pour refléter les informations de votre propre organisation. L’important ici est de veiller à ne laisser aucune des valeurs en blanc :

~/easy-rsa/vars

set_var EASYRSA_REQ_COUNTRY "US"

set_var EASYRSA_REQ_PROVINCE "NewYork"

set_var EASYRSA_REQ_CITY "New York City"

set_var EASYRSA_REQ_ORG "DigitalOcean"

set_var EASYRSA_REQ_EMAIL "admin@example.com"

set_var EASYRSA_REQ_OU "Community"

set_var EASYRSA_ALGO "ec"

set_var EASYRSA_DIGEST "sha512"

Lorsque vous avez terminé, enregistrez et fermez le fichier. Si vous utilisez nano, vous pouvez le faire en appuyant sur CTRL+X, puis Y et ENTER (ENTRÉE) pour confirmer. Vous êtes maintenant prêt à construire votre AC.

Pour créer la paire de clés root public et privé pour votre autorité de certification, exécutez à nouveau la commande ./easy-rsa, cette fois-ci avec l’option build-ca :

./easyrsa build-ca

Dans la sortie, vous verrez quelques lignes sur la version OpenSSL et vous serez invité à entrer une phrase de passe pour votre paire de clés. Assurez-vous de choisir une phrase de passe solide, et notez-le dans un endroit sûr. Vous devrez saisir la phrase de passe chaque fois vous devrez interagir avec votre AC, par exemple pour signer ou révoquer un certificat.

Il vous sera également demandé de confirmer le Nom commun (CN) de votre AC. Le nom commun est le nom utilisé pour désigner cette machine dans le contexte de l’autorité de certification. Vous pouvez saisir n’importe quelle chaîne de caractères pour le nom commun de l’AC mais, par souci de simplicité, appuyez sur ENTER (ENTRÉE) pour accepter le nom par défaut.

Output

. . .

Enter New CA Key Passphrase:

Re-Enter New CA Key Passphrase:

. . .

Common Name (eg: your user, host, or server name) [Easy-RSA CA]:

CA creation complete and you may now import and sign cert requests.

Your new CA certificate file for publishing is at:

/home/sammy/easy-rsa/pki/ca.crt

Remarque : Si vous ne voulez pas qu’un mot de passe vous soit demandé à chaque fois que vous interagissez avec votre AC, vous pouvez exécuter la commande build-ca avec l’option nopass, comme ceci :

./easyrsa build-ca nopass

Vous disposez maintenant de deux fichiers importants - ~/easy-rsa/pki/ca.crt et ~/easy-rsa/pki/private/ca.key - qui constituent les composants publics et privés d’une autorité de certification.

•.ca.crt est le fichier de certificats public de l’AC. Les utilisateurs, les serveurs et les clients utiliseront ce certificat pour vérifier qu’ils font partie du même réseau de confiance. Chaque utilisateur et serveur qui utilise votre AC devront avoir une copie de ce fichier. Toutes les parties s’appuieront sur le certificat public pour s’assurer qu’une personne ne se fait pas passer pour un système et n’effectue pas une attaque de type Man-in-the-middle.
•.ca.key est la clé privée que l’AC utilise pour signer les clés et les certificats des serveurs et des clients. Si un intrus accède à votre AC et, à son tour, à votre fichier ca.key, vous devrez détruire votre AC. C’est pourquoi votre fichier ca.key ne doit se trouver que sur votre machine AC et votre machine AC doit idéalement être maintenue hors ligne lorsqu’elle ne signe pas de demandes de certificat, par mesure de sécurité supplémentaire.

Avec cela, votre AC est en place et elle est prête à être utilisée pour signer des demandes de certificats et pour révoquer des certificats.

Étape 4 — Distribuer le certificat public de votre autorité de certification

Votre AC est maintenant configurée et prête à agir comme une racine de confiance pour tous les systèmes que vous voulez configurer pour l’utiliser. Vous pouvez ajouter le certificat de l’AC à vos serveurs OpenVPN, serveurs web, serveurs de messagerie, etc. Tout utilisateur ou serveur qui doit vérifier l’identité d’un autre utilisateur ou serveur de votre réseau devrait avoir une copie du fichier ca.crt importé dans le magasin de certificats de son système d’exploitation.

Pour importer le certificat public de l’AC dans un deuxième système Linux comme un autre serveur ou un ordinateur local, obtenez d’abord une copie du fichier ca.crt de votre serveur AC. Vous pouvez utiliser la commande cat pour le sortir dans un terminal, puis le copier et le coller dans un fichier sur le deuxième ordinateur qui importe le certificat. Vous pouvez également utiliser des outils comme scp, rsync pour transférer le fichier entre les systèmes. Cependant, nous utiliserons un copier-coller avec nano dans cette étape car cela fonctionne sur tous les systèmes.

En tant qu’utilisateur non root sur le serveur AC, exécutez la commande suivante :

cat ~/easy-rsa/pki/ca.crt

Il y aura une sortie dans votre terminal qui ressemblera à ce qui suit :

Output

-----BEGIN CERTIFICATE-----

MIIDSzCCAjOgAwIBAgIUcR9Crsv3FBEujrPZnZnU4nSb5TMwDQYJKoZIhvcNAQEL

BQAwFjEUMBIGA1UEAwwLRWFzeS1SU0EgQ0EwHhcNMjAwMzE4MDMxNjI2WhcNMzAw

. . .

-----END CERTIFICATE-----

Copiez tout, y compris les lignes -----BEGIN CERTIFICATE----- et ------END CERTIFICATE----- et les tirets.

Sur votre deuxième système Linux, utilisez nano ou votre éditeur de texte préféré pour ouvrir un fichier appelé /tmp/ca.crt :

nano /tmp/ca.crt

Collez le contenu que vous venez de copier du serveur AC dans l’éditeur. Lorsque vous avez terminé, enregistrez et fermez le fichier. Si vous utilisez nano, vous pouvez le faire en appuyant sur CTRL+X, puis Y et ENTER (ENTRÉE) pour confirmer.

Maintenant que vous disposez d’une copie du fichier ca.crt sur votre deuxième système Linux,il est temps d’importer le certificat dans le magasin de certificats de son système d’exploitation.

Sur les systèmes basés sur Debian et Ubuntu, exécutez les commandes suivantes pour importer le certificat :

Debian and Ubuntu derived distributions

cp /tmp/ca.crt /usr/local/share/ca-certificates/

update-ca-certificates

Pour importer le certificat du serveur AC sur un système basé sur CentOS, Fedora ou RedHat, copiez et collez le contenu du fichier sur le système tout comme dans l’exemple précédent dans un fichier appelé /tmp/ca.crt. Ensuite, vous copierez le certificat dans /etc/pki/ca-trust/source/anchors/, puis vous exécuterez la commande update-ca-trust.

CentOS, Fedora, RedHat distributions

sudo cp /tmp/ca.crt /etc/pki/ca-trust/source/anchors/

update-ca-trust

Votre deuxième système Linux fera maintenant confiance à tout certificat qui a été signé par le serveur AC.

Remarque : si vous utilisez votre AC avec des serveurs web et si vous utilisez le navigateur Firefox, vous devrez importer directement le certificat ca.crt public dans Firefox. Firefox n’utilise pas le magasin de certificats du système d’exploitation local. Pour plus de détails sur la façon d’ajouter le certificat de votre AC à Firefox, veuillez consulter cet article de Mozilla sur la configuration des autorités de certification (AC) dans Firefox.

Si vous utilisez votre AC pour intégrer un environnement Windows ou des ordinateurs de bureau, veuillez consulter la documentation sur la façon d’utiliser certutil.exe pour installer un certificat d’AC.

Si vous utilisez ce tutoriel comme condition préalable à un autre tutoriel, ou si vous savez comment signer et révoquer des certificats, vous pouvez vous arrêter ici. Si vous souhaitez en savoir plus sur la façon de signer et de révoquer des certificats, la section facultative suivante vous expliquera chaque processus en détail.

(Facultatif) — Création de demandes de signature de certificats et révocation des certificats

Les sections suivantes du tutoriel sont facultatives. Si vous avez effectué toutes les étapes précédentes, vous disposez d’une autorité de certification entièrement configurée et opérationnelle que vous pouvez utiliser comme condition préalable pour d’autres tutoriels. Vous pouvez importer le fichier ca.crt de votre AC et vérifier dans votre réseau les certificats qui ont été signés par votre AC.

Si vous souhaitez vous entraîner et en savoir plus sur la manière de signer des demandes de certificat et sur la manière de révoquer des certificats, ces sections facultatives vous expliqueront comment fonctionnent les deux processus.

(Facultatif) — Création et signature d’une demande de certificat de pratique

Maintenant que vous avez une AC prête à l’emploi, vous pouvez vous entraîner à générer une clé privée et une demande de certificat pour vous familiariser avec le processus de signature et de distribution.

Une demande de signature de certificat (CSR) se compose de trois parties : une clé publique, des informations d’identification sur le système requérant, et une signature de la requête elle-même, qui est créée en utilisant la clé privée de la partie requérante. La clé privée sera gardée secrète et sera utilisée pour chiffrer les informations que toute personne possédant le certificat public signé pourra ensuite déchiffrer.

Les étapes suivantes seront exécutées sur votre second système Linux Debian, Ubuntu ou une distribution dérivée de l’un de ces systèmes. Il peut s’agir d’un autre serveur distant, ou d’une machine Linux locale comme un ordinateur portable ou un ordinateur de bureau. Comme easy-rsa n’est pas disponible par défaut sur tous les systèmes, nous utiliserons l’outil openssl pour créer une clé privée et un certificat de pratique.

openssl est généralement installé par défaut sur la plupart des distributions Linux, mais juste pour en être certain, exécutez ce qui suit sur votre système

sudo apt update

sudo apt install openssl

Lorsque vous êtes invité à installer openssl, entrez y pour poursuivre les étapes d’installation. Maintenant, vous êtes prêt à créer une pratique CSR avec openssl.

La première étape que vous devez suivre pour créer une CSR est la génération d’une clé privée. Pour créer une clé privée en utilisant openssl, créez un répertoire “practice-csr” et générez ensuite une clé à l’intérieur de celui-ci. Nous allons faire cette requête pour un serveur fictif appelé sammy-server, par opposition à la création d’un certificat qui est utilisé pour identifier un utilisateur ou une autre AC.

mkdir ~/practice-csr

cd ~/practice-csr

openssl genrsa -out sammy-server.key

Output

Generating RSA private key, 2048 bit long modulus (2 primes)

. . .

e is 65537 (0x010001)

Maintenant que vous avez une clé privée, vous pouvez créer une CSR correspondante, à nouveau en utilisant l’utilitaire openssl. Vous serez invité à remplir un certain nombre de champs comme Pays, État et Ville. Vous pouvez saisir un . si vous souhaitez laisser un champ vide, mais sachez que s’il s’agit d’une véritable CSR, il est préférable d’utiliser les valeurs correctes de votre localisation et votre organisation :

openssl req -new -key sammy-server.key -out sammy-server.req

Output

. . .

-----

Country Name (2 letter code) [XX]:US

State or Province Name (full name) []:New York

Locality Name (eg, city) [Default City]:New York City

Organization Name (eg, company) [Default Company Ltd]:DigitalOcean

Organizational Unit Name (eg, section) []:Community

Common Name (eg, your name or your server's hostname) []:sammy-server

Email Address []:

Please enter the following 'extra' attributes

to be sent with your certificate request

A challenge password []:

An optional company name []:

Si vous souhaitez ajouter automatiquement ces valeurs dans le cadre de l’invocation openssl plutôt que via l’invite interactive, vous pouvez passer l’argument -subj à OpenSSL. Assurez-vous de modifier les valeurs mises en évidence pour qu’elles correspondent à votre lieu d’exercice, à votre organisation et au nom de votre serveur :

openssl req -new -key sammy-server.key -out server.req -subj \

/C=US/ST=New\ York/L=New\ York\ City/O=DigitalOcean/OU=Community/CN=sammy-server

Pour vérifier le contenu d’une CSR, vous pouvez lire dans un fichier de requête avec openssl et examiner les champs à l’intérieur

openssl req -in sammy-server.req -noout -subject

Output

subject=C = US, ST = New York, L = New York City, O = DigitalOcean, OU = Community, CN = sammy-server

Une fois que vous êtes satisfait de l’objet de votre demande de certificat de pratique, copiez le fichier sammy-server.req sur votre serveur AC en utilisant scp

scp sammy-server.req sammy@your_ca_server_ip:/tmp/sammy-server.req

Au cours de cette étape, vous avez généré une demande de signature de certificat pour un serveur fictif appelé sammy-server. Dans un scénario réel, la demande peut provenir d’un serveur web de développement ou de simulation qui a besoin d’un certificat TLS pour des tests, ou d’un serveur OpenVPN qui demande un certificat pour que les utilisateurs puissent se connecter à un VPN. Au cours de l’étape suivante, nous allons passer à la signature de la demande de signature de certificat en utilisant la clé privée du serveur AC.

Assurez-vous que vous êtes connecté à votre serveur AC en tant qu’utilisateur non racine et exécutez les opérations suivantes, en substituant l’IP ou le nom DNS de votre propre serveur à la place de your_server_ip :

scp ~/easy-rsa/pki/crl.pem sammy@your_server_ip:/tmp

Maintenant que le fichier est sur le système distant, la dernière étape consiste à mettre à jour tous les services avec la nouvelle copie de la liste de révocation.

Mise à jour des services qui prennent en charge une LCR

L’énumération des étapes à suivre pour mettre à jour les services qui utilisent le fichier crl.pem dépasse la portée de ce tutoriel. En général, vous devrez copier le fichier crl.pem à l’emplacement prévu par le service, puis le redémarrer à l’aide de systemctl.

Une fois que vous aurez mis à jour vos services avec le nouveau fichier crl.pem, vos services pourront rejeter les connexions des clients ou des serveurs qui utilisent un certificat révoqué.

Examen et vérification du contenu d’une LCR

Si vous souhaitez examiner un fichier CRL, par exemple pour confirmer une liste de certificats révoqués, utilisez la commande openssl suivante à partir de votre répertoire easy-rsa sur votre serveur AC :

cd ~/easy-rsa

openssl crl -in pki/crl.pem -noout -text

Vous pouvez également exécuter cette commande sur tout serveur ou système qui dispose de l’outil openssl installé avec une copie du fichier crl.pem. Par exemple, si vous avez transféré le fichier crl.pem sur votre second système et que vous souhaitez vérifier que le certificat de sammy-server est révoqué, vous pouvez utiliser une commande openssl comme celle qui suit, en introduisant le numéro de série que vous avez noté précédemment lorsque vous avez révoqué le certificat à la place de numéro mis en évidence ici :

openssl crl -in /tmp/crl.pem -noout -text |grep -A 1 8348B3F146A765581946040D5C4D590A

Output

Serial Number: 8348B3F146A765581946040D5C4D590A

Revocation Date: Apr 1 20:48:02 2020 GMT

Remarquez comment la commande grep est utilisée pour vérifier le numéro de série unique que vous avez noté dans l’étape de révocation. Vous pouvez maintenant vérifier le contenu de votre liste de révocation de certificat sur tout système qui s’appuie sur elle pour restreindre l’accès aux utilisateurs et aux services.

Conclusion

Dans ce tutoriel, vous avez créé une autorité de certification privée en utilisant le package Easy-RSA sur un serveur Debian 10 autonome. Vous avez appris comment fonctionne le modèle de confiance entre les parties qui s’appuient sur l’autorité de certification. Vous avez également créé et signé une demande de signature de certificat (CSR) pour un serveur de pratique, puis appris à révoquer un certificat. Enfin, vous avez appris comment générer et distribuer une liste de révocation de certificats (LRC) pour tout système qui dépend de votre AC afin de s’assurer que les utilisateurs ou les serveurs qui ne devraient pas accéder aux services en soient empêchés.

Vous pouvez maintenant délivrer des certificats pour les utilisateurs et les utiliser avec des services comme OpenVPN. Vous pouvez également utiliser votre AC pour configurer des serveurs web de développement et de simulation avec des certificats afin de sécuriser vos environnements de non-production. L’utilisation d’une AC avec des certificats TLS pendant le développement peut contribuer à garantir que votre code et vos environnements correspondent autant que possible à votre environnement de production.

Si vous souhaitez en savoir plus sur l’utilisation d’OpenSSL, consultez notre page sur les principes essentiels d’OpenSSL : Travailler avec les certificats SSL, les clés privées et les CSR contient de nombreuses informations supplémentaires pour vous aider à vous familiariser avec les principes fondamentaux d’OpenSSL.